wowwikifandomcom-20200223-history
Patch 5.4.0/API changes
Breaking Changes * new 'bidderFullName' and 'ownerFullName', return values, not added at the end: ..., highBidder, bidderFullName(13), owner, ownerFullName(15), saleStatus, .... * players tool-tip changes adding text to denote Coalesced Realm players. two visible lines as one tool-tip line. * inter-realm player names are now separated by a '-' dash, and not ' - ' space dash space. this change is true for all APIs and display text. Critical Bugs * Slider 'valueStep' property does not affect the UI 'thumb' slider when moved. behaves like 'valueStep' is default. Additions * Changes to support Connected Realms * Slider stepsPerPage="(number)", (), (number) - to move 'per page' * widget method () - is secure widget instance. related to ScopedModifier forbidden="true". Important Notes * For those still unaware, the Blizzard WoW AddOn Kit are no longer updated. See notes on Interface AddOn Kit for notes on using the console to extract the files locally. Blue Posts * Almost no official API change posts this time. See Wow Interface for community discussion and summaries on the Patch 5.4.0 API changes. Coalesced and Connected Realms See Connected Realms and Coalesced Realms. Player Tooltips Now that connected realms are more becoming a 'thing', text was added to clarify which players are 'coalesced' from other types player realm relationships. Text has been added to player tool-tip for anytime a player has been temporarily Coalesced into the same zone and is not from 'your' realm. This applies when a player was placed into a battleground, world zone, or otherwise, from more than one zone, and now has special text which currently is localized, static, and placed at the bottom of the tooltip. In particular, as of 17399: * the text is static, and mearly added when there is a cross realm, coalesced player. * text looks like three new lines at the end, but only takes two real tooltip lines, the last two. * a new COALESCED_REALM_TOOLTIP localized global matches the added tooltip text, excepting the converted '\n'. * enUS version of the Lua constant text is "Coalesced Realm (*)\nGroup, Whisper". '\n' is an actual newline char in the tooltip itself. * a " ", line with a single 'space' char is added before the new text to the tooltip. * all other player and NPC 'hover', and SetUnit(unit), tooltip text works the same as before. * would *not* expect this setup to remain unchanged, and should be more dynamic in the future. Slider Slider now uses Slider:GetStepsPerPage and Slider:SetStepsPerPage as a seperate steps per page value for stepping when user is clicking the bar, as opposed to dragging the thumb control. The a 'page' action will step the slider value in multiples of the 'value step' property as defined by 'steps per page' property. Issues As of 17359, when using the thumb control for Slider, the 'value step' property is ignored, which causes any thumb control movement to change the value, and allows every intermediate value to be set. This happens using either 'valueStep' attribute or 'SetValueStep' Lua function. The 'value step' property does however appear to correctly affect the new 'steps per page' property. Workaround: Currently the accepted workaround is to use the 'on changed event' to feed the current values back into SetValue, so that it can get clipped, and then use the resultant value from GetValue again. The setter will need to be guarded against infinate loop, as below: function TestSlider_OnValueChanged(self, value) -- start fix if not self._onsetting then -- is single threaded self._onsetting = true self:SetValue(self:GetValue()) value = self:GetValue() -- cant use original 'value' parameter self._onsetting = false else return end -- ignore recursion for actual event handler -- end fix _Gself:GetName().."Text":SetText(value) -- handle the event end Note: This will still get to the handler once per-mouse move (plus all the good previous behaviour), however will have the actual correct value. If you let only value changes, via some kind of 'if value value_ then return end', then you will miss the inital 'set' events and other previous effects. When the slider is moved the modulus/fractional value will erroniously get set each update, ignoring the Step property. Setting the value back to the slider foces it to get clipped, but only set if not already in the middle of setting. Because the visual update won't occur until after the UI events are all done, the slider wont actualy move, but the mouse can continue to travel until reaches the next step. This is pretty much forward and backward compatable drop in fix. Currently the default UI hasa places that grind to a halt due to settings are being changed every mouse move in the config pages. Test Setup -- start fix if not self._onsetting then -- is single threaded self._onsetting = true self:SetValue(self:GetValue()) self._onsetting = false else return end -- ignore recursion for actual event handler -- end fix _Gself:GetName().."Text":SetText(self:GetValue()) -- test values self:SetMinMaxValues(1,16) self:SetValueStep(2) self:SetStepsPerPage(3) self:SetValue(5); self:RegisterForDrag("LeftButton") self:StartMoving() self:StopMovingOrSizing()